build(nix): declare build inputs explicitly and fix dev shell env - #1781
Open
mmclinton wants to merge 4 commits into
Open
build(nix): declare build inputs explicitly and fix dev shell env#1781mmclinton wants to merge 4 commits into
mmclinton wants to merge 4 commits into
Conversation
added 4 commits
August 10, 2026 10:15
The build asks for these by name, but none of them were listed: CMake resolves wayland-scanner with find_program(... REQUIRED), reads wayland-protocols' pkgdatadir through pkg-config, requires OpenSSL for the crypto lib and the vendored sqlcipher, requires X11 for the xcb window manager, and links xkbcommon and udev by bare name. They resolved anyway, because qt6.qtbase propagates openssl, libx11, libxcb, libxcb-keysyms, libxkbcommon, systemd and wayland-scanner, and kdePackages.layer-shell-qt propagates wayland-protocols. Nothing declares that arrangement and nothing tests it. d344b47 is why it matters. Unvendoring the merged protocols made system wayland-protocols a hard configure-time requirement, FATAL_ERROR and all. nix/vicinae.nix was not touched, and the Nix build stayed green only because layer-shell-qt happened to carry it. Whenever that path is disturbed, by a buildInput dropped or a nixpkgs bump that changes what Qt propagates, configure fails with "wayland-protocols not found" in a diff that has nothing to do with Wayland. The derivation already sets strictDeps, so this finishes a rigour it had opted into. Every package added here was already in the build graph at the same version, so the closure is unchanged.
systemd only reads modules-load.d from /etc, /run and /usr/lib, and NixOS generates /etc/modules-load.d from boot.kernelModules. The vicinae.conf we install into the store path is therefore inert, and it suggests the package takes care of loading uinput when it does not. Loading uinput on NixOS belongs in the NixOS module, not here.
CMAKE_C_COMPILER and CMAKE_CXX_COMPILER are not environment variables.
CMake reads CC and CXX and stores their values into the CMAKE_*_COMPILER
cache entries; unlike CMAKE_TOOLCHAIN_FILE it never looks the compiler
variables up in the environment, so both exports were no-ops.
CC and CXX were redundant too: the shell is already built with
mkShell.override { stdenv = package.stdenv; }, package.stdenv is
gcc15Stdenv, and gcc15Stdenv.cc is pkgs.gcc15, the same wrapper the
stdenv puts on PATH and exports itself. Pinning them by hand also
quietly defeated that override, since the shell would have kept using
gcc 15 if effectiveStdenv ever moved on.
With the compiler exports gone, the hook only carries the QML import
paths, and those are just as useful on macOS, so the isLinux guard on
the shellHook goes too.
Ref: https://cmake.org/cmake/help/latest/envvar/CC.html
The dev shell builds a qtEnv aggregating qtdeclarative, qtsvg, qtimageformats, qttools and, on Linux, qtwayland and layer-shell-qt, but pointed the QML import paths at qtdeclarative alone. Comparing the two trees, that hid exactly the modules the aggregate exists for: org.kde.layershell and QtWayland.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
I've been building Vicinae from the flake and working in
nix develop, and went looking for why a couple of things behaved oddly in the dev shell. That turned into four small commits: two on the package, two on the dev shell. The only change to the built output is the removed (inert)modules-load.dfile; every other installed byte is identical. The evidence is in the collapsed section at the bottom so you can reproduce it rather than take my word for it.Each commit stands alone, so happy to split this, drop any part, or reshape it entirely.
0ab07cfenix/vicinae.nix5943d423nix/vicinae.nixlib/modules-load.d/vicinae.conf, which nothing reads from a store path441b65a4flake.nixshellHookexports that are duplicates or no-ops85521f69flake.nixqtEnvthe shell already builds1. Undeclared dependencies (
0ab07cfe)nix/vicinae.nixsetsstrictDeps = true, so I expectedbuildInputsto be the complete picture. The CMake actually requires eight things that aren't in it:wayland-scannerandwayland-protocols(cmake/Wayland.cmake), OpenSSL (src/lib/crypto,vendor/sqlcipher),X11::xcb/X11::xcb_keysyms(src/server), and the barexkbcommon/udevlink names (src/server,src/lib/linux-utils,src/snippet).They resolve today because
qt6.qtbaseandlayer-shell-qtpropagate all eight transitively.Nothing is broken. The reason to declare them anyway is that the arrangement is invisible exactly when it matters. Two cases from this repo, and neither is a criticism, they're the point:
find_package(OpenSSL REQUIRED), and did updatenix/vicinae.nixin the same change (swift/apple-sdkfor Darwin), yet openssl still didn't get added, because propagation meant nothing ever failed.wayland-protocolsa hard configure-time requirement (FATAL_ERRORwhen absent).nix/wasn't touched, and stayed green becauselayer-shell-qthappened to carry it.If a nixpkgs bump ever changes what Qt propagates, configure fails with
wayland-protocols not foundin a diff that has nothing to do with Wayland, and whoever bisects it has a bad afternoon. I read this as finishing whatstrictDepsalready opted into, but if you'd rather deliberately lean on Qt's propagation and keep the list minimal, that's a fair call and I'll drop this commit.2.
modules-load.d(5943d423)INSTALL_MODULES_LOAD_CONFIGdefaults toON, so the package installs$out/lib/modules-load.d/vicinae.conf. systemd only readsmodules-load.dfrom/etc,/runand/usr(/local)/lib, and NixOS generates/etc/modules-load.dfromboot.kernelModules, so in a store path the file is inert, and it reads as though the package handles loadinguinputwhen it doesn't. Same shape of problem as #1607 (a package manager wanting to own installed files, there for Gentoo); the two compose rather than conflict. That PR adds a coarse switch, and the Nix build wants the existing fine-grained one, since it does want the themes, desktop file and icon.3. Dev shell (
441b65a4,85521f69)Both are artifacts of ordering rather than anything anyone got wrong.
441b65a4: #1129 addedexport CC=${pkgs.gcc15}/bin/gcc(andCXX) to get gcc 15 into the shell, which was the right fix at the time. #1545 later rebuilt the shell asmkShell.override {stdenv = package.stdenv;}, and sincegcc15Stdenv.ccispkgs.gcc15(verified below), the exports became a second copy of what the stdenv already does. The twoCMAKE_*_COMPILERexports were no-ops all along: CMake readsCC/CXXfrom the environment and never theCMAKE_*_COMPILERvariables (verified below, and documented). With the compiler exports gone the hook only carries the QML import paths, so this commit also drops theisLinuxguard on theshellHook: qmlls is equally useful on macOS. Say the word if you'd rather keep it guarded.85521f69: #1189 introduced the aggregateqtEnv; #1636 later added the QML import paths so qmlls could see Nix-installed QML modules, but pointed them atpkgs.qt6.qtdeclarativerather than theqtEnvthat already existed, so qmlls saw a subset of what the shell provides (org.kde.layershellandQtWaylandwere missing). This is really just finishing #1636.Verification: how I checked nothing changed (x86_64-linux, flake's pinned nixpkgs)
Nothing new enters the build. The
.drvclosures ofmainand this branch differ only in vicinae's own derivation, its source tree, and the two fixed-outputnpm-depsderivations (whose output hashes are pinned, so their outputs are identical):All eight packages were already in main's build closure at identical versions:
systemd-minimal-libs-259(nixpkgs'udev),wayland-protocols-1.47,libxkbcommon-1.11.0,wayland-scanner-1.24.0,libxcb-1.17.0,libxcb-keysyms-0.4.1,libx11-1.8.12,openssl-3.6.1. All but wayland-protocols are inqt6.qtbase'spropagatedBuildInputs; wayland-protocols is inlayer-shell-qt's.The installed tree is byte-identical. I built both derivations and compared the outputs after replacing each output's self-referencing store hash with a fixed placeholder (the store paths necessarily differ, and the binaries embed their own
$out). The only difference left is themodules-load.dremoval:The runtime closure holds one version of each library.
openssl-3.6.1-bin/-devdo appear, butnix why-dependsshows they arrive throughnodejs(thebin/vicinaewrapper'sPATH->nodejs->openssl-dev), which predates this change.Package:
nix build -L .#defaultgreen;lib/modules-load.dgone; all six installed programs present (bin/vicinaeplus five underlibexec/vicinae/). The built launcher runs (vicinae server --openon Wayland/GNOME: window opens, app search and launch work).Dev shell:
nix develop -c sh -c '$CC --version'->gcc (GCC) 15.2.0, unchanged.gcc15Stdenv.cc == pkgs.gcc15->true(nix evalagainst the pinned nixpkgs).The CMake claim, tested empirically in the shell:
CMAKE_CXX_COMPILER=/nonexistent cmake ...configures fine (env var ignored);CXX=/nonexistent cmake ...fails withCMAKE_CXX_COMPILER not set(env var read).$QML_IMPORT_PATHnow resolvesorg/kde/layershell/{qmldir,LayerShellQtQml.qmltypes}, and the delta against plain qtdeclarative is exactly the two missing trees:Hygiene:
alejandra --check .clean. Eval is warning-free: the commit uses the top-levellibx11/libxcb/libxcb-keysymsattributes because the pinned nixpkgs deprecates thexorg.*set ("The xorg package set has been deprecated",pkgs/top-level/aliases.nix). The package and dev shell also evaluate cleanly at each of the four commits, and still evaluate foraarch64-darwin.Not verified: macOS beyond evaluation. The Linux-only additions sit inside the existing
lib.optionals isLinuxblocks, so the Darwin path should be untouched, but I'd appreciate a check from someone who can build it.Happy to clarify any of these further.